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Through a phased development as a laboratory-based research testbed the N * SA ( 0A * T uh T ? l h * r ®n! 
Testbed provides an environment for system test and demonstration of the technology which will 
usefully complement, significantly enhance, or even replace manned space activities. By 
integrating advanced sensing, robotic manipulation and intelligent control under h “ m8n ' ,nt . e c ra ^’]'* 
supervision the Testbed will ultimately demonstrate execution of a variety of generic tasks 
suggestive of space assembly, maintenance, repair, and telescience. The Testbed system t* 8 *^*® 8 
hierarchical layered control structure compatible with the incorporation of evolving * 8C * ® 9 

as ?hey become available. The Testbed system is physically implemented in a computing 
architecture which allows for ease of integration of these technologies wh ' le pres8rv \ n9 *^ 8 
flexibility for test of a variety of man-machine modes. This paper reports on the development 
currently ^n progress on the functional and implementation architectures of the NASA/OAST Testbed 
and capabilities planned for the coming years. 

1.0 PERSPECTIVE 

With the advent of a manned Space Station and renewed Shuttle missions and in response to rising 
world competition, Congress has mandated the National Aeronautics and Space Administration (NASA) 
to vi gorously deve l op automat i on and robotics with the goal of improving productivity in space 
while lowering overall mission cost, reducing risk to manned space missions, and, th * *®" 9 * p 
term? transferring robotics technology to industry so as to strengthen its global economic 

pos i t i on . 

NASA has apportioned each of its centers a role in bringing this mandate to fruition. The Jet 
Propulsion ^Laboratory (JPL) has been designated by the Off ice of Aeronautics and Space J *—!!!!» 
(NASA/OAST) to be the lead center for identifying and developing flight qualifiable robotics 
system technologies through the development of a Telerobot Testbed. Technologies developed a * 
will be transferred to Goddard's Space Flight Center for integration with their * P ® C * , St8 !i?" 
Flight Telerobotic Servicer ( FTS) and Shuttle Development Test Flight (DTF-1 , DTF-2) arms. This 
paper describes JPL's ongoing efforts to realize these goals. 

1.1 THE NASA/OAST TEIEROBOT TESTBED PROJECT - PROJECT OBJECTIVES 

The NASA/OAST Teterobot Testbed (TRTB) project is implementing a Telerobot Te . st ^ ed at . J r P a L t . far 
purpose of developing, integrating, and testing telerobot subsystems and demonstrating new 
te?e?obot technologies As a goal, the Telerobot Testbed seeks to identify and '^P^ent ^stem 
technologies envisioned to be cardinal to flight teterobot systems. Technology research and 
development is conducted in support of NASA's manned and unmanned space programs and is designed 
to sustain on-orbit servicing, assembly, inspection and maintenance tasks. 

Under the current plan, the Testbed will be upgraded each year to meet technology objectives 
identified in Reference 1. Uith time the Testbed is expected to progress to greater levels of 
machine autonomy. Testbed demonstrations are expected to grow in complexity, duration , and 
automation. Successive years will build upon capabilities of previous years and technologies 
developed in earlier years will be incorporated into the Testbed permanently. 

Technologies currently envisioned for implementation into the Testbed include traded and shared 
control allowing for enhanced man/machine interaction, Teleoperation with short time delays, 
autonomous operation in uncertain and cluttered environments, system fault recovery, operation in 
a dynamic environment, and dexterous manipulation. Testbed deliverables include mature Testbed 
Interface Specification and Functional Requirements documents, a database of Telerobot system and 
subsystem performance, and a series of capability demonstrations which provide an indication of 
the Testbed technologies' maturity and their degree of readiness for transfer to space operations. 
The TRTB project also expects to deliver a hardware and software database for ground and flight 
prototype systems which identifies, for the first time. Telerobot system performance criteria, 
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power requirements, computing, data storage and bandwidth requirements, software 
control laws, fallback approaches to task execution, and margins for system growth. 


algori thms 


for 


Through the Testbed project, future flight programs will come to understand technical tradeoff 
'ssues understand requirements for qualifying flight Telerobot systems, and benefit from 
standardized interfaces and modularized hardware and software developed in the Testbed. From its 
experience the Testbed may grow to become a national resource for validating new space telerobot 
technology and flight operations sequences. K 


2.0 THE '89 NASA/OAST TELEROBOT CONCEPTUAL ARCHITECTURE 


Conceptually, the NASA/OAST Telerobot Testbed architecture follows a hierarchical design 
philosophy which places the human and machine intelligences towards the top of the control 
hierarchy and the primitive or mechanical telerobot functions towards the bottom (Figure 1). Five 
subsystems, not including the human operator, comprise the Telerobot Testbed system*. In 
descending order on the hierarchy they are: the Operator Control Station (OCS), Task Planning & 
Reasoning (TPR ) , Run Time Control (RTC), Sensing and Perception (S&P), Manipulators and Control 
Mechanization (MCM). Although the Testbed subsystems are physically located in the same facility 
an artificial division was introduced between the higher level subsystems (Operator OCS TPR) and 
the lower level subsystems (RTC,MCM, S&P) in anticipation of having to accommodate missions where 
Operator and manipulators are separated by time delay. Such delays occur whenever the Operator 
and the worksite are separated by signal propagation time. 


The Telerobot (TR) manipulator arms are controlled through one of two possible paths. In 
teleoperated modes, the Operator commands the manipulators directly through Hand Controllers 
available to him at the OCS. In autonomous modes, the machine intelligence (TPR) manipulates the 
arms through RTC. With time the Testbed project expects to fuse the direct path between MCM and 
the Operator with the autonomous path so that teleoperations, including shared control, will pass 
down through TPR. For telerobot systems whose local and remote sites are collocated, TPR/RTC will 
look like a wire connecting MCM and the Operator. Whenever the local and remote sites are 
separated by distance, the TPR will perform the function of simulating the remote environment so 
that in effect the Operator teleoperates locally. Task execution at the remote site will occur 
one delay time later. 


The Testbed architecture may also be thought of as being composed of three layers. At the lowest 
layer is its physical makeup which includes subsystem hardware and software. At the next layer 
are the operational modes which define the states subsystems take on, and at the top layer are the 
Telerobot’s fundamental capabilities. Capabilities may be defined as a specific configuration of 
selected subsystem states arranged to focus on a common mission goal. Complex tasks are 
constructed from these capabilities. These three layers are discussed in greater detail next. 

3.0 THE *89 TELEROBOT TESTBED SYSTEM IMPLEMENTATION 

Figure 2 is a functional diagram of the Telerobot Testbed as it is currently implemented. Higher 
level functions are grouped in subsystems toward the top of the hierarchy and lower level 
functions are grouped in subsystems toward the bottom. The Telerobot architecture is also divided 
between lower level functions concentrated at the remote site (all subsystems to the right of the 
Ethernet) and higher level functions concentrated at the local site (all subsystems to the left of 
the Ethernet). The TRTB project expects to introduce in FT *90 a delay capability into the 

Testbed to investigate teleop control algorithms with propagation delays between the Operator and 
manipulators. Testbed subsystems communicate over a common Ethernet local area network. A 
Network Interface Package software hosted on subsystem VAX computers supports the functions of 
accepting and transmitting packets of formatted commands or data. A description of the six TRTB 
subsystems follows: 

3.1 OPERATOR CONTROL STATION SUBSYSTEM 

The Operator Control Station sits at the top of the Telerobot Hierarchy providing an efficient 
user friendly physical interface between the Telerobot Testbed Operator and Test Conductor (TC) 
and Testbed subsystems. OCS is composed of two work stations, multiple video monitors switchable 
to different camera or video buffer sources, a stereo vision display, speakers, microphones, three 
keyboards, a mouse, function switches, two Force Reflecting Hand Controllers ( FRHC) , and support 
computers. 

The OCS software provides a table-driven system for easy editing or updating of command definition 
and data. A terminal emulation capability allows the Operator to interface directly through the 
OCS console with all other Testbed subsystems. Over the Testbed’s common Ethernet, OCS accepts 
and displays information to the Operator or TC from the subsystems, and relays Operator commands 
back to the subsystems. Through the two Hand Controllers, the Operator teleoperates the two 

Testbed manipulator arms. Force/torque sensors at the end-effectors backdrive the Hand 
Controllers, allowing the Operator to “sense" forces and torques induced at the end effectors. 
Both the Operator and TC have limited voice control command capabilities, including system 


186 



on/off/halt, camera arm movement, and selected teleop commands. Two cross- strapped 
Buttons" Interface directly to the manipulator arms providing the Operator and TC with an 
overriding emergency halt capability. 

3.2 TASK PLANNING & REASONING SUBSYSTEM 

The Task Planning & Reasoning subsystem sits at the top of the autonomous control 
providing the Telerobot's machine intelligence. TPR performs functions of high level task and 
gross motion planning. The subsystem interacts with the Operator accepting task assignment, plan 
changes, plan concurrences, and direct action requests and translates them into processes for RTC 
execution. 

The subsystem consists of a gross motion spatial planner, task planner, a kinematics simulator, 
and a coordinator to pass knowledge between these reasoning engines. The task planner generates 
over-all task plans and selects the actions to be performed as appropriate to the current state of 
objects in the workspace and recently experienced manipulation failures. The gross motion spatial 
planner generates collision free paths through the workspace for the manipulator arm and carried 
object. The kinematics simulator conceives possible manipulator arm configurations to reach 
objects, approach points, or other features of the workspace. 

TPR maintains a database of objects (World Model) in the worksite, including their 

locations/orientations, connectivity, and semantic relationships. During Testbed oparat ions the 
database is routinely updated from sensor information provided either by SSP and MCM through RTC, 
or by Operator designation of objects in the workspace. The World Model also incorporates a 
Collision Detection unit and a geometric reasoner which maintains rules and information trees on 
relationships between objects in the workspace, logically deduces which changes n the 
relationships are permissible, and assists the Operator in correcting or completing positional 
information about objects in the knowledge database. 

3.3 RUN TIME CONTROL SUBSYSTEM 

The Run Time Control subsystem, together with TPR, provides the Telerobot with the capability to 
function autonomously. RTC's role is to provide fine motion and grasp planning commands to MCM. 

RTC consists of a subsystem System Executive supported by robotics, interface, communications, and 
infrastructure support modules. Briefly, upon receiving commands from TPR or the Operator/OCS, 
RTC reformats them into internal RTC data structures, selects a script to match the requested TPR 
process, selects a path for the arms, kinematically simulates the selected sequence, checking for 
collisions, pose flips and joint stops, generates local motion and coordination level 
the manipulator arms and end-effectors, and passes executable macros on to MCM and S&P. During 
operations RTC monitors sequence execution, evaluating and modifying ongoing actions as needed. 

RTC maintains and intermittently updates a database of workspace object 

based either on information gathered from S&P and MCM or the Operator through TPR. The database 
maintains accurate geometric and inertial models of the three Telerobot arms and immobi le _ objects 
in the workspace. A Geometric Relationship Evaluator accomplishes frame transformations and 
maintains correct connectivity relationships among objects in the workspace. 

3.4 SENSING AND PERCEPTION SUBSYSTEM 

The Sensing and Perception Subsystem performs four system functions: 1) It provides the Operator 

on five OCS monitors with live or still, stereo and mono black and white video images of the 


workspace from nine Testbed cameras and four video frame buffers and provides MCM with object 
location/orientation state data. Five of the cameras also serve to provide S&P with stereo 
machine vision; 2) S&P tracks an object in the workspace as it moves about * U PP 1 ^ «* t *^**® 



object in the workspace, - — ■» ■ . , , , , . . 

RTC and MCM; 4) From a database of objects in the workspace, S&P provides wire-frame models of the 
objects for display as graphic overlays on OCS monitors. These overlays support the Object 
Designate and Fixture Verification functions. 

3.5 MANIPULATORS AND CONTROL MECHANIZATION SUBSYSTEM 

The Manipulator and Control Mechanization subsystem sits at the bottom of the Telerobot hierarchy 
providing the Telerobot with manipulation capability and the mechanical interface to the 
workspace. The subsystem consists of two six degree-of -freedom robot arms, actuators, servoed 
end-ef fectors force-torque sensors, universal controllers, the two Force Reflecting Hand 
Controllers at the Operator console with their attendant electronics, Universal Controllers, a SUN 
which hosts trajectory generation software, a MicroVax which hosts communications interface 
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software. Macros to enable a variety of Telerobotic actions, and a variety of other support 
software. MCM also provides and controls a third six degree-of- freedom arm for positioning the 
stereo vision camera arm. 

MCM receives commands from and transmits information back to the Operator through one of two 
control paths. In teleoperation mode MCM receives position/orientation commands directly from the 
Operator through the FRHC's and returns force/torque information from the end-effectors. In 
autonomous modes MCM receives position/orientation and force/torque commands over the Ethernet 
from RTC and, if in shared control mode, returns position/orientation and force/torque data back 
to the Hand Controllers. Position/orientation states of objects in the worksite come to MCM from 
S&P. 

4.0 THE MASA/OAST TELEROBOT TESTBED *89 OPERATIONAL SYSTEM CAPABILITIES 

In FY*89 five new technology capabilities will be introduced into the Testbed: teleoperation with 
force reflection, traded control, single and dual arm shared control. Operator designation, and 
self calibration. These capabilities will augment the Reactive Control and Verification 
capabilities currently available in the Testbed. These capabilities were conceived as being 
cardinal or so-called generic in nature allowing complex tasks to be constructed from elementary 
ones. Shared control permits the human and machine intelligences to work cooperatively while 
traded control allows them to work sequentially. These capabilities are described next. 

4.1 FORCE REFLECTION IN TELEOPERATION 

In Teleoperation, the Operator controls the TR's manipulator arms by providing the six 
position/orientations through the Hand Controllers to MCM. Manipulator path planning, collision 
avoidance, arm coordination, and object manipulation are performed by the Operator in real time. 
The force-reflection capability returns force/torque information back through MCM to the Hand 
Controllers from the robot wrist sensors allowing the Operator to "feel" the force/torques at the 
end-effector. 

4.2 TRADED CONTROL 

In the most general sense, traded control is a transfer of control between Operator teleoperation 
and Telerobot autonomous control anywhere and at any time during task execution. In the TRTB's 
*89 version of Traded Control the Operator performs all gross motion planning, maneuvering the 
end-effectors to a point in the proximity of an object and transfers control to the Telerobot for 
autonomous manipulation of the object. Upon completion of the task the Telerobot moves its end- 
effector to a point in the vicinity of the object and offers to transfer control back to the 
Operator. During autonomous execution the Operator may elect to transfer control and continue 
task execution in teleoperation. Also, the Operator may elect to transfer to autonomous control 
during fine teleoperation execution. At all times the Operator has overriding control and can 
elect to Halt a task. MCM's role during traded control is to provide a smooth transition from 
teleoperation to autonomous control and back to teleoperation as well as the continuous control of 
arm trajectories through singularities. 

4.3 SINGLE AND DUAL ARM SHARED CONTROL 

In the most general sense Shared Control allows for manipulator control to be shared jointly 
between the autonomous Telerobot and the Operator teleoperating force reflecting Hand Controllers. 
Both single and dual arm shared control have been implemented into the Testbed. 

In single arm shared control the Operator selects to control one or more of six possible object 
positions/orientations through one hand controller and MCM controls the remaining 
positions/orientations, as well as the six force/torque compliances applied to the object by the 
end-effector. Force reflection from the end-effector is optional. 

The dual arm shared control capability makes possible coordinated dual arm manipulation of rigid 
objects. The Operator selects to control through one Hand Controller one or more of six possible 
positions/orientations of an object and the Telerobot controls the remaining 
positions/orientations as well as all force/torque compliances applied to the object by both arms. 

4.4 OPERATOR DESIGNATE 

The Operator Designate capability provides wire-frame models (WFM) of objects in TPR's database to 
the Operator to manually overlay over still camera images of the objects in the workspace on the 
Operator's OCS console and read out the locations/orientations of the objects. The Operator thus 
locates objects in the workspace for TPR for subsequent manipulation. Designation can also be 
used to update the location/orientation of known objects in the workspace, define obstacle 
regions, and designate generic objects. 
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4.5 SELF CALIBRATION 


Self Calibration is an autonomous capability similar to Verification which provides the Telerobot 
databases with improved knowledge of an object's location/orientation in the workspace. It 
improves on the systematic error limitation inherent in Verification by measuring the relative 
distance between two objects instead of the distance between the objects and the camera. 

4.6 REACTIVE CONTROL 

Reactive Node is a capability which enables spinning satellite grapple. S&P provides a continuous 
updated state vector of the satellite to MCM. MCM then determines arm trajectories required to 
grapple the rotating satellite. 

4.7 VERIFICATION 

Verification is an autonomous capability which provides Testbed databases with refined knowledge 
of the Testbed objects' location/orientation in the workspace. It improves on the error 
limitation inherent in Operator Designation. A verification is executed only after a Designation. 

5.0 THE 1989 NASA/OAST TELEROBOT TESTBED VALIDATION DEMONSTRATION 

Telerobot Testbed demonstrations are a synthesis of telerobot technology capabilities, convoked 
elementary task sequences, and human participation which, when arranged intelligently, engender 
robust telerobot activity mimicking human activity. They are the deliverables against which the 
degree of success of attaining TRTB project objectives is measured and against which the 
worthiness of identified technologies for space applications can be evaluated. Successful 
demonstration outcomes are a prerequisite to the Testbed technology receiving acceptance for 
space-based operations on manned and unmanned missions. Technology transfer to a flight project 
happens once a demonstration proves the technology to be safe and reliable and telerobot risks and 
performance are well understood. 

The task selected for the 1989 Telerobot Testbed technology validation demonstration is an Earth 
Orbiting System (EOS) Orbital Replacement Unit (ORU) changeout. This demonstrat ion wi l l validate 
the five new TRTB technologies. In an operation mimicking on-orbit satellite servicing, a tray- 
looking ORU subtended by a large instrument mockup is exchanged with a smaller instrument mounted 
on a nearby stowage rack. Two bolts attaching the ORU to the platform are unbolted and, in a dual 
arm cooperative action, the ORU is detached from the EOS platform and mounted on the rack. The 
smaller instrument mounted on the stow rack is then removed by a single arm, attached to the EOS 
platform, and then bolted. Figure 5 depicts the ORU with its accompanying instrument, the stow 
rack, and the smaller instrument on the rack. Table 1 is a step by step top-level description of 
the demonstration. The first column lists the EOS tasks while the second identifies the '89 
technology capabilities validated. The third column is an attempt to look beyond the 
demonstration and to identify those capabilities which are generic to flight telerobots- - that is, 
those capabilities which a mature flight telerobot system is envisioned to possess. 

The Operator's role in the EOS validation demonstration will be to initiate each task step, select 
the control modes, designate fixtures in the workspace, and perform all gross arm motions. The 
Telerobot's role in the EOS validation demonstration will be to visually identify familiar objects 
in the workspace after a Designation, calibrate the relative positions of objects before a 
transfer to traded control, perform fine motion planning and arm/tool manipulation, and while in 
shared control, control selected position/orientations and all force/torques applied to object by 
the manipulator arm or arms. 

6.0 MEASURING TELEROBOT TESTBED SYSTEM PERFORMANCE 

The Telerobot Testbed performance will be measured at three levels and evaluated at a fourth. 
These levels are inclusive of all possible functions for the TRTB. More generally, these levels 
are valid for other robot architectures and are suggested as a framework from which to evaluate 
the adequacy of telerobot performance. 

At the lowest level of system performance are level 1 subsystem stand-alone tests which validate 
the hardware and software designs of the telerobot subsystems. These tests seek to verify 
performance against design requirements, and typicatly consist of software execution checks, 
intramodule information transfer, hardware voltages, etc. At level 2, performance tests seek to 
verify performance against subsystem interface requirements and consist of inter-subsystem 
compatibility tests between the telerobot subsystems. Level 2 tests typically consist of 
transmitting and receiving commands correctly between subsystems, properly processing commands, 
switching among video displays, timing checks, etc. Tests at levels 1 and 2 when they are 
unsuccessful are typically typified by rework of hardware or software elements. 

Ultimately, however, telerobot performance must be measured at the system level. It is here that 
the telerobot's technology capabilities are tested. Unlike a single purpose tool, thousands of 
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tests can be performed to demonstrate telerobot capability performance. However, if chosen 
intelligently, a finite number of tests or technology validation demos are sufficient to prove 
technology capability robustness to perform demonstration tasks and in turn the telerobot's 
performance limits can be assessed. Of course telerobot work in space will undoubtedly be reduced 
to a finite number of tasks and those tasks will be specifically checked multiple times in 
multiple configurations in the Testbed before attempt is made on-orbit. Level 3 system 
performance, not yet wholly defined, is measured in such terms as tolerance to expected and 
unexpected changes in the environment, reliability, error recovery, tolerance to measurement 
errors, stability, and database consistency. When tests at level 3 are unsuccessful or degraded, 
they are typically corrected by design modification or capability 
modification/reconceptualization. Limits to performance are assessed through multiple 
demonstrations with multiple tasks. 

At the highest level of test the Telerobot's generic capabilities are validated and its degree of 
readiness to perform specific space servicing operations is evaluated. No physical tests are made 
at this level. Rather performance observed during level 3 demonstrations serves to validate the 
TRTB's readiness to perform multiple space servicing operations. The criteria for evaluating 
system performance here is to match the Telerobot capabilities against those envisioned for flight 
missions, including backup operations, redundancy and fault protection in system/operations, 
delineate limits to the Telerobot's performance, understand its handicaps, and understand risks 
inherent in its design. 

7.0 THE NBS NASREM CONCEPTUAL ARCHITECTURE 

The National Bureau of Standards (NBS) has advanced a conceptual telerobot architecture known as 
the NBS Standard Reference Model as its candidate for space Telerobots. In its most general form 
NASREM (Figure 3, Reference 7) is partitioned into three hierarchies, each with six vertical 
levels plus the interface between the robot and the World. As with the NASA/OAST architecture, 
higher functions are placed towards the top and lower functions towards the bottom. Conceptually, 
the Operator can interact directly at any level. All modules have access to a Global memory* 
NASREM ‘ s database. Modules within each hierarchy (vertical data flow) accept commands from higher 
level modules and transform them into instructions for lower level modules. Across hierarchies 
(horizontal data flow) modules interact through the World Model with modules in another hierarchy 
and at any level. The NASREM architecture accommodates growth by adding more levels at the top. 
For example, NASREM's Service Bay level accommodates one telerobot executing multiple tasks at 
different sites and the Service Mission level accommodates multiple telerobots operating at 
multiple jobs at multiple sites. 

The TRTB project calls for developing and validating technology which ultimately will be 
integrated with GSFC's Space Station Flight Telerobotic Servicer ( FTS) and Development Test Flight 
(DTF-1 , DTF-2) arms. Since FTS has accepted a requirement to conform to the NASREM telerobot 
architecture, a mapping was established between the NASA/OAST Telerobot Testbed architecture and 
the NASREM architecture (see Figure 4, Ref. 6). Roughly, the NASA/OAST Telerobot functions 
described earlier are reproduced by the first four NASREM levels. 

7.1 DIFFERENCES BETWEEN THE NASREM AND THE *89 NASA/OAST TELEROBOT ARCHITECTURES 

Comparison of the NASREM and NASA/OAST architectures reveals subtle differences. However, the 
differences between the two architectures are deemed minor and do not preclude technology transfer 
from the NASA/OAST Telerobot Testbed to the NASREM FTS. A list of these differences follows: 

1) NASA/OAST World Model vs NASREM Global Database 

TPR, RTC, and MCM utilize separate, subsystem-specific but consistent data bases whereas NASREM 
uses one integrated data base. In the NASA/OAST design database, information flows directly and 
to some extent simultaneously between subsystems while in the NASREM architecture information must 
flow serially into and out of the Global Database. Thus TRTB subsystems need neither to interrupt 
other subsystems nor be time-coordinated when accessing database information. Dashed lines in 
Figure 3 depict data flow which is direct in the JPL Testbed but must pass through the GDB in the 
NASREM architecture. 

2) Time Delay Between Local and Remote Sites 

In future developments, the Telerobot Testbed expects to accommodate time delays between the local 
(Operator/TPR) and remote (RTC/MCM/S&P) subsystems whereas the NASREM architecture does not 
specifically address this issue. Tests in teleoperations show that deterioration in eye/arm 
coordination makes it impossible for a human to perform complex tasks with the Telerobot arms 
whenever the round trip time delay between the Operator and end-effectors is greater than two 
seconds. The NASA/OAST architecture expects to accommodate teleoperations under such conditions 
with a more robust TPR than is required without time delay and without a requirement for 
synchronization between the Operator and the remote manipulator arms. In this concept the 
Operator interacts with a TPR generated simulation of the manipulators and sensors, rather than 
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with the actual 
TPR/RTC 1 s model of 
which are sent to 
messages . 


Testbed manipulators. Forces on the end-effectors are predicted based on 
the world. The Operator's interactions with the simulation produce commands 
the remote site for execution and the remote site asynchronously returns status 


3) Data Base Updates 

The MASA/OAST Telerobot Testbed is concerned with paths and tasks in the vicinity of an object in 
the work-space while MASREN is concerned with activities in the whole workspace. Thus when 
updating the Testbed databases only subsystems with an interest in the ongoing activity are 
updated The update is restricted to information about the local work space only and the Operator 
iTrequired to be cognizant of activities in the rest of the workspace. In contrast updating the 
NASREM Global Data Base requires an extensive run through the entire database, thereby introducing 
a potential delay in task execution. 


4) Operation Modes 


The MASA/OAST architecture follows the NASREM philosophy in that the Operator can interact with 
the telerobot at all levels in the hierarchy. However, MASA has implemented teleoperation, shared 
control, and traded control modes whereas NASREM is a yet undefined mix of teleoperation and 
autonomous control. 


5) Kinematics 


NASREM incorporates knowledge of robot kinematics at the E-move level and lower while the 
NASA/OAST architecture incorporates it at the TPR level and lower, thereby providing the TRTB with 
a more robust level-4 capable of increased task planning, task replanning, and path planning. 


6) Dynamics 

NASREM incorporates knowledge of robot dynamics at the primitive level and lower while the 
NASA/OAST architecture incorporates it at the RTC level and lower, thereby providing the TRTB with 
a more robust level -3 capable of increased local path planning and recovery. 

8.0 SUMMARY AND CONCLUSIONS 

NASA is embarking on a program dedicated to increasing productivity on-orbit while reducing 
mission costs and risk to astronauts. Its Jet Propulsion Laboratory has been designated as the 
lead center for identifying and developing flight robotics technologies. JPL is currently 
implementing a Telerobot Testbed project which seeks to 1) provide a testbed for robotics system 
integration and technology demonstrations, 2) provide a laboratory or prototype laboratory where 
flight operations can be evaluated, 3) transfer technology to NASA standard telerobotic arms used 
on Space Station and STS such as the GSFC FTS and DTF systems, 4) and, for the first time, 
identify system issues and performance criteria for flight telerobots. 

This paper described the TRTB 1 s system architecture (Figures 1, 2) as well as its five new 
caDabi l ities. Criteria for testing telerobot system performance at the subsystem design level, at 
the integrated system level, and at the demonstration level, and evaluating its generic 
capabilities were discussed. The role of demonstrations in the Testbed and the demonstration 
chosen for the '89 Testbed were described. 

Technology developed and tested in the TRTB will be transferred to GSFC's FTS and DTF arms as 
candidate technology for implementation. The teleoperated FTS and DTF u!sa/qast 
requirements to conform to the NASREM architectures. Differences between the NASREM and NASA/OAST 
architectures were identified and for the first time a mapping (Figure 4) between two telerobot 
architectures was established. 
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FIGURE 1; THE NASA/OAST TELEROBOT TESTBED ARCHITECTURE - '89 CONFIGURATION 
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FIGURE 2: THE NASA/OAST TELEROBOT TESTBED IMPLEMENTATION ARCHITECTURE - ’B9 CONFIGURATION 


SENSORY WORLD 

PROCESSING MOOEUNG 


TASK 

DECOMPOSITION 


DETECT 

INTEGRATE 


MODEL 

EVALUATE 


PLAN 

EXECUTE 



FIGURE 3: THE NBS NASREM STANDARD REFERENCE MODEL 
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TABLE 1: THE *89 TELEROBOT TESTBED VALIDATION DEMONSTRATION 


EOS TASKS 

1 - OPERATOR LOCATES ARMS. TOOLCRffi. 

STOWBJN OBJECTS IN WORKSPACE 

2 - toemFY FOR TELEROBOT ARMS. TOOL CRB. 

STOWBJN. TASK BOARD. BOLTS ON ORU/INSTR. 

3- MOVE ARM-1 TO VJCJNfTY OF TOOLCRC 
4. GET WRENCH 

5 - MOVE ARM-1 TO VCJNTTY OF ORU 

6 • REMOVE BCLT-1 ATTACHMG ORU TO 

EOS PLATFORM 

7 - MOVE ARJ4>t TO VCMTY TOOLCRO 

8 • RETURN TOOL TO TOOLCRB 

9 • REPEAT PROCEDURE WITH ARM-2 

10 - MOVE ARM-1 ANO ARM-2 TO VJOMTY ORU 

11 - GRASP HANDLE- 1 ON ORU 

12 - GRASP HANDLE-2 ON ORU 

13 -DETACH ORU FROM EOS PLATFORM 

14 - MOVE ORU TO STOW RACK 

15 - ATTACH ORU TO STOW RACK 

16- UNGRASP ORU HANDLES 

17 - MOVE ONE ARM TO VICJNmr OF SMAa 

WSTRUMENT 

18 - GRASP HANDLE ON SMALL NSTRUUENT 

19 - DETACH SMALL NSTRUMEWT FROM STOW RACK 

20 - MOVE SMALL INSTRUMENT TO VICINITY OF 

EOS PLATFORM 

21 - ATTACH SMALL INSTRUMENT TO PLATFORM 

22 - MOVE ARM TOVONTTY OF TOOLCR® 

23 -GET WRENCH 

24 * MOVE ARM TO VICINTTY OF SMALL NSTRUMENT 

25 - BOLT SMALL INSTRUMENT TO PLATFORM 

26 - RETURN TOOL TO TOOLCRB 


•89 CAPABILITIES VALIDATED 

CAMERA VISION FOR OPERATOR 

OCS DESIGNATE FUNCTION; DATABASES UPDATED 

TELEOPERATIONS {SINGLE ARM. GROSS ARM MOTIONS) 

TRADED CONTROL • TRANSITION FROM/TO TELEOPERATIONS TO/FROU AUTONOMOUS 
CONTROL 

SAME AS {3) 

TRADED CONTROL SELF -CAL IB RATION 

SAME AS {3) 

TRADED CONTROL 
SAME AS (3) THROUGH (8) 

TELEOPERATIONS (TWO ARMS. GROSS ARM MOTIONS) 

TRADED CONTROL SELF-CALIBRATION 

TRADED CONTROL SELF-CALIBRATION 


GENERIC CAPABILITIES VALIDATED 

OPERATOR VISUALLY IDENTIFIES OBJECTS/FEATURES, LOCATIONS/ORIENTATIONS IN 
THE WORKSPACE 

TELEROBOT VISUALLY IDENTIFIES 08JECTS/FEATURES. LCttATIONS/ORlENTATIONS IN 
THE WORKSPACE; COMMUNICATIONS BETWEEN TELEROBOT1C SUBSYSTEMS AND 
OPERATOR; UPOATES DATABASE 

TELEOPERATION (SINGLE ARM. GROSS MOTIONS) 


SAME AS (3) 

AUTONOMOUS FWE MOTION PATH PLANNING. ENGAGE BOLT. TWIST BOLT OFF. UPDATE 
DATABASE 

SAME AS (3) 

AUTONOMOUS FINE MOTION PATH PLANNING. RELEASE TOOL TO TOOL CRIB 
CAPABILITY TO OPERATE TWO ARMS WOftflOUALLY 
TELEOPERATION {DUAL ARM, GROSS MOTION) 

AUTONOMOUS FINE MOTION PATH PLANNING. RETURN TO OPERATOR IF 
UNRESOL VABLE ERROR OCCURS. GRASP HANDLE WITH FORCE CONSTRAINT. 

UPOATE DATABASE- 

SAME AS (11) 


DUAL-ARM SHARED CONTROL * REMOVE OBJECT ATTACHED BY TWO P»NS. OPERATOR 
PROVIDES POSITION/ORIENTATION OF OBJECT AND TELEROBOT AUTONOMOUSLY 
PROVIDES PCSmONS/ORJENTATIONS AND FORCE/TORQUE COMPLIANCE APPLIED TO 
ORU BY BOTH ARMS 

SAME AS (13) - MANIPULATE OBJECT 


TELEROBOT REMOVES OBJECT ATTACHED BY TWO PINS WITH COORDINATED DUAL- 
ARM ACTION MAINTAINING POSITlON/ORlENTATION. FORCE/TORQUE CONTROL. 
OPERATOR PROVIDES PATH PLANNING AND SENSES FORC E/TORQUES. 


TELEROBOT MANIPULATES OBJECT WITH COORDINATED OUAL-ARM ACTION. 
MAINTAINING POSITlON/ORlENTATION. FORCE/TORQUE CONTROL. OPERATOR 
PROVIDES PATH-PLANNMG. 


SAME AS (13) -TWO PIN INSERTION 


TELEROBOT INSERTS OBJECT (TWO-PW INSERTION) WITH COORDINATED OUAL-ARM 
ACTION MAJNTAMNG POSITlON/ORlENTATION. FORCE/TORQUE CONTROL UPOATK 


TELEOPERATIONS (UNGRASP) 
SAME ASP) 


TELEOPERATION (UNGRASP COMMAND) 
SAME ASP) 


SAME AS (11) 


SAME AS (11) 


SINGLE-ARM SHARED CONTROL - REMOVE OBJECT ATTACHED BY ONE PIN OPERATOR 
PROVIDES PCSmONS/ORIENT ATIONS FOR ARM AND TELEROBOT PROVIDES 
FORCE/TOR OUE COMPLIANCE APPLIED TO INSTRUMENT. FORCE REFLECTION ENABLES 
OPERATOR TO FEEL FORCES AT ENO-EFFECTOR. 


TELEROBOT REMOVES OBJECT (ONE PIN) WITH SWGLE-ARM ACTION UAINTAWNG 
POSITlON/ORlENTATION. FORCE/TORQUE CONTROL OPERATOR PROVIDES PATH 
PLANNING AND SENSES FORCE/TORQUES INOUCED ON OBJECT. 


SAME AS (19) - MANIPULATE OBJECT WITH FORCE FEEDBACK 


SAME AS (3) 


SAME AS (19) - SINGLE PIN INSERTION 
SAME ASP) 

SAME AS (4) 

SAME AS (3) 

TRADED CONTROL: SELF-CALIBRATION 


SAME AS (8) 


SAME AS (19) - SINGLE PIN INSERTION , SELF CALIBRATION 
SAME AS(3) 

SAME AS (4) 

SAME ASP) 

AUTONOMOUS FINE MOTION PLANNING, ENGAGE BOLT. TWIST BOLT ON. UPDATE 
DATABASE. 

SAME AS (8) 




